全链版 2048：我们从 MUD 引擎使用中学到了什么？
TL; DR
MUD 引擎的设计遵循“数据库本位”
全链游戏的 AMM 时刻尚未到来
加密原生是一种价值观
开始之前
mud2048.fun 是我们为获得对全链游戏开发的微观体感展开的一次探索，旨在通过复刻体验无限接近原始 2048 游戏（play2048.co）的全链上版本，来实地感受全链游戏开发的水温，获得一线的体感。
本文是对本次开发过程中习得的经验、展开的思考汇总，抛砖引玉，以飨读者。
这大约是对全链游戏（Fully On-chain Games）开发最简单的尝试，在此之前我们的曾尝试实现 Chrome 离线恐龙游戏（Chrome Dino Game）的全链上版，后发现没有区块链原生游戏 Tick 机制的支持，很难复刻在体验与原游戏接近的全链版本。
这里可能涉及一个常见误区：简单游戏更容易实现全链上版本。实则不然，由于区块链的交易确认时间（即便是主流 Layer 2）尚未达到中心化服务器的接口响应时间水平；加之将游戏逻辑上链之后，带来了中心化场景里未曾出现的工程复杂度，导致并非所有简单的休闲游戏都能够轻松实现全链版。这也一定程度上解释了当前全链游戏生态的分野：
以 RTS（实时策略类游戏）为主，如：Loot Survivor、Primodium、Sky Strife、Cellula等，以 Meta Rules（元规则类游戏/沙盒游戏）为辅，如：PixeLAW、Briq、OpCraft等。这两类游戏均在游戏形态上规避了区块链交易确认时间较长带来的弊端。
为什么选择 MUD 引擎？
MUD 是 EVM 生态首款全链游戏引擎（也是 EVM 生态首款应用程序开发框架），引擎内置的 Session wallet ，以及可通过 API 调用的测试链 Faucet 可降低玩家进入门槛。
另一个原因是 MUD 开源，文档及社区资料较多，易于上手。游戏引擎是否开源涉及到商业模式问题下文再专门讨论。
下面进入正题，将谈论一些我们在使用 MUD 引擎过程中的一些心得体会，有宏观感性的行业层面、也有微观理性的工程实操层面，面向的受众群体不同，大家可自行取用（直接跳过不感兴趣的部分）。
工程篇
总的来说，MUD 引擎是什么？
MUD 引擎 = 链上关系型数据库 + 链上应用开发框架。
这个是一个站在互联网领域看区块链领域的视角（有点类似站在陆权看海权），肯定不是最恰当的角度，但考虑到区块链尚未实现 Mass Adoption，区块链产品要出圈，依然需要吸引更多互联网领域的用户，所以不妨先从互联网的视角来看分析。
不论是“链上关系型数据库”还是“链上应用开发框架”，都对以太坊这台“世界计算机”的发展来说至关重要。
从互联网应用开发中我们学到：数据库软件的好用程度/数据库表结构设计的合理程度，很大程度上决定了整个项目开发的复杂度。换句话说，互联网应用开发是以数据库为核心的展开的，我们姑且称之为“数据库本位”。
那么我们看看，MUD 引擎的设计是否也遵循了“数据库本位”的思想。从 MUD 引擎的设计思路看，它核心解决三个问题：
1. 链上数据如何易于读写且以经济的方式存储，
2. 链上/客户端之间的自动数据同步，
3. 应用开发的普遍复杂性管理。
我们先来看第一个问题：“链上数据如何易于读写且以经济的方式存储”。
这个问题可以拆解为两个要素：
1> 易于读写
2> 经济存储
“易于读写”这个点经过互联网领域几十年的实践，“关系型数据库”被认为是最优解。虽然区块链是非常不同于传统数据库存储模式的链式存储模式（见下图），该模式即便对于单一场景的简单操作都很不友好（比如对某 NFT Collection 的交易额求和/求均值/求最大最小值等），更别提更进一步的复杂场景。
因此，MUD 的解法是在链式存储之上，实现“关系型数据库”（对应 MUD 引擎中 Store下的 Table）。对开发者来说，使用体验如同操作常见的关系型数据库（如：MySQL、SQL Server、PostgreSQL、SQLite 等）。这一点确实对广大互联网开发者比较友好。下图为我们基于 MUD 引擎开发全链版 2048 时，对应的表结构。
“经济存储”这个点，我们可以从以太坊这台世界计算机的角度来分析。
现代计算机均符合“冯诺依曼结构”，该结构分为：输入、输出、运算、控制、存储五部分（见下图）。
从全链游戏引擎自身的角度讲，它能优化其实也只有“存储”，因为“输入”、“输出”在它的上层，它控制不了；“运算”、“控制”是以太坊区块链自身在做的事情。全链游戏引擎作为运行在这台“世界计算机”之上的“基础应用软件”来说，它能优化的只有经由它输入的“存储”。
对存储的优化，具体方案是对输入数据实现非常高效且紧凑的“位打包”（bitpacking），由于在区块链上存储数据是按数据体积收费的，因此，更小的数据体积意味着更低廉的存储成本。充分优化过的存储成本是，大规模复杂链上应用出现的前提。下图为 MUD 对存储优化的具体案例，详见《全链游戏引擎 MUD 从0到V2》。
综上，对于问题一，MUD 主要就是从“数据库本位”的角度切入，来解决问题的。
现在我们来到第二个问题：“链上/客户端之间的自动数据同步”。
这也是 MUD 引擎提供的一个核心功能，帮开发者省去了自己管理复杂状态同步的繁重工作。具体实现方案是：在客户端对链上数据库的实时同步，换句话说，每个客户端都有一个内置的、与链上数据库实时同步的本地副本。
这主要是通过 MUD 引擎中的 Indexer 实现的。下图为 MUD 官方对 Indexer 的介绍，主要面向想在搭建运行在项目方服务器上的场景（当然该描述也同样适用于，自动运行在全链游戏客户端内的 Indexer）。
图片来源：https://mud.dev/services/indexer
对开发者来说，初步拥有了一个使用体验接近本地数据库的链上数据库。不过就目前 MUD 的实现来说，客户端难以实现诸如生成全局榜单这样的功能；另外，让每个客户端生成一遍全局榜单，也不是一个经济的做法。
说到这里，这里大家肯定会问：为什么不在链上生成全局榜单？原因是 MUD 引擎虽然实现了初步的关系型数据库，但关系数据库中的常见的求和/求均值/求最大最小值等功能，MUD 尚未支持。
因此，在 mud2048.fun 中，我们在中心化服务器上搭建 MUD Indexer 节点，来以成本收益相对平衡的方式生成全局玩家排行榜（见下图）。
网址：https://www.mud2048.fun/
不过让每个客户端拥有一个链上数据库的实时副本，也有弊端的。比如在应用启动前需要先从链上同步数据，以在本地建立链上数据库的最新副本，这会增加玩家进入游戏的等待时间。MUD 官方也意识到了该问题，在 MUD V2 版本中提到了相关优化方案（分段数据同步和客户端缓存），不过在我看来都属于临时方案，不能彻底解决随时间推移，待同步的链上数据越来越多的问题。
这个问题暂时看是无解的（短期很难在公网数据传输效率和链式数据检索方面取得大的突破），希望随着 MUD 的迭代，能找到更恰当的解决方案。如果这个问题得到很好的解决，也能为其他链上复杂应用的诞生铺平道路。
现在我们来到问题三：“应用开发的普遍复杂性管理”。
在此之前，以太坊生态的链上应用多数比较简单（一个客观指标是，不论DeFi/NFT/DAO 单一产品所涉及的合约数量有限，且多数情况下部署后更新的可能性很小）。但对于复杂应用开发来说，逻辑更新、访问控制、权限管理都是需要从头做一遍的重复劳动。因此非常需要一个通用型框架/引擎，统一帮开发者处理这些问题，以便开发者可以全身心投入应用开发。
MUD 引擎提供的另一个核心功能便是，通过 World 模块帮助开发者省去处理上述问题的时间，具体而言，World 提供了在 Store 之上的逻辑和访问控制，下图为 MUD 官网对 World 的描述，这是一般应用开发框架都会提供的功能，这里不再赘述。
图片来源：https://mud.dev/world/introduction
对复杂应用开发来说，访问控制（或者叫路由）是决定总体工程量很重要的环，访问控制设计的优劣，直接决定了应用开发的复杂度和易维护性。MUD 显然也很重视这一点，下图为 MUD v1 和 v2两个版本中对其访问控制模块的优化。
以上是我们在使用 MUD 引擎开发 mud2048.fun 的过程中，在工程方面的一些思考与体会。总体来看，MUD 引擎也遵循了“数据库本位”的思想，这跟互联网应用开发的方法论高度一致，因此对互联网应用开发者来说，MUD 引擎不会让他们感到陌生。接下来我们将探讨对全链游戏行业方面思考。
行业篇
当我们进入全链游戏领域的时候，不断追问自己的三个问题是：
1. 为什么需要全链游戏？
2. 什么样的游戏适合全链上？
3. 全链上（Fully on-Chain）与加密原生（Crypto native）到底什么关系？
接下来我们逐一讨论：
对于第一个问题：为什么需要全链游戏？
这个问题可以进一步拆解为两个子问题：
1> 区块链行业为什么需要全链游戏？
2> Crypto 市场为什么需要全链游戏？
从区块链行业看：
以太坊生态发展到了需要复杂链上应用出现的阶段（过去的链上应用DeFi/DAO/NFT均较为简单，支撑一个应用的合约数量可见一斑），另一个反向的例证是以太坊 Layer 2 对全链游戏的扶持。从内在逻辑看，没有瓷器活，炼不成金刚钻，Layer 2 需要全链游戏这些瓷器活来成就自己。
NFT 领域在 PFP 泡沫后一直没有新的范式促进其发展，而 NFT 区别于 ERC-20 的点是可组合性，游戏场景是 NFT 天然的可组合性场所。
全链游戏的终极目标“自主世界”，是对数字世界终极形态又一次阐述（上一次阐述是被过度营销化后烂大街的“元宇宙”）。自主世界作为人类对美好未来的共同想象，具有很好的号召力，而全链游戏作为实现该目标的重要途径，也被寄予厚望。
从 Crypto 市场看：
回顾互联网发展史，游戏总是最先采用新技术领域，游戏属于 Consumer App，更容易触达终端用户。
链游/GameFi 模式暂时被证伪，对区块链游戏的探索重新回到了游戏的本源：游戏性。基于区块链的游戏性（完全继承了区块链的优点和缺点）有望提供过去没有的全新体验和范式，从而吸引用户。
我们来到第二个问题：什么样的游戏适合全链上？
目前看行业/市场对这一点尚未达成共识，从归纳法的角度看，以前文提到的实时策略类（RTS）和元规则类（Meta Rules）两个类别居多。但创新不足、商业模式不清晰、未能很好的匹配到用户等问题依然是这个领域绕不开的问题。
个人认为，元规则（Meta Rules）类相对更有潜力，因为至少能在规则层面、互操作性层面有更多原生的可能性，不过现在还很早期，尚难以评估其确定性，下图为元规则类全链游戏 PixeLAW 的界面。
游戏间的互操作性，相当长的时间内可能都是个伪命题。虽然全链游戏继承了区块链的互操作性，但从商业/产品/生态角度，短期很难想象两个独立产品间面向互操作性来开发，以及这个点也在之前“元宇宙”周期内被一定程度上证伪。
现在我们来谈论第三个问题：全链上（Fully on-Chain）与加密原生（Crypto native）到底什么关系？
首先，过度强调“全链上”会使人陷入原教旨主义的怪圈，区块链现在的基础设施难以支撑广泛类别的游戏将数据/逻辑全部上链。另外《黑暗森林》创始人 GubSheep，最初的提法是“Crypto-Native Games”，以期从 Crypto-Native 的角度，思考游戏如何最大程度上促进区块链行业的发展。下图为 GubSheep 原文局部。
加密原生（Crypto native）是个内涵不断变化，且边界相对模糊的概念。在区块链发展的不同阶段，有不同的诠释。
在 2017 年，CryptoKitties 被认为是加密原生的典范；
在 2018 年，Uniswap 是加密原生的典范；
在 2020 年，CryptoArt 是加密原生的典范；
在 2021 年，DAO 是加密原生的典范；
到了 2023 年，数据和逻辑都在链上的全链游戏，被看作是加密原生的典范。
但本质上加密原生是一种思想，而非一种教条。
全链上（Fully on-Chain）是践行加密原生（Crypto native）的方法论，但不能因之作茧自缚，就像中心化/去中心化、革命/反革命一样，都是相对概念，过于纠结字面容易走入死胡同。
那么，无论全链上游戏还是加密原生游戏，到底带来了哪些新的可能性？
我认为，将游戏逻辑/规则通过上链透明化后，所有游戏策略可以真正公平竞争，当然还需要找到能够体现这种优势的场景。举例来说，因为游戏逻辑都在链上，可以直接写合约代码来玩游戏，再加上 AI 生成玩法策略，可能会让我们拥有一个高于平均水平/不眠不休的虚拟玩家代理（这个想法受 Shoshin 启发）。
此外，像 MUD 这样的全链游戏引擎（其实叫它全链应用开发框架更合适），作为数据库 + 应用开发框架合体的存在，在 EVMs 生态的重要性不言而喻。但数据库/应用开发框架都属于公共物品，本身毫无商业模式可言。不过好在有区块链原生的 Token 机制，以及像 EIP-6969 这样的开发者版税方案，能够帮助这些公平物品开发者，以一种外部的方式捕获价值，这是区块链优于 Web2 的点。
“共识”不单是 51% 的算力，更是存乎社会/群体间的共有价值观，从这个意义上说，加密原生是一种价值观。
附录：
1. MUD 2048 官网： https://www.mud2048.fun/
2. MUD 2048 项目代码：https://github.com/themetacat/MUD2048
3. MUD 引擎官网： https://mud.dev/
4. Autonomous Worlds 圣经官网：https://aw.network/
5. GubSheep 加密原生游戏理论：https://gubsheep.substack.com/p/the-strongest-crypto-gaming-thesis